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REPLACEMENT SUMMARY SECTION OF APPEAL BRIEF 



Sir: 

In response to the Notification of Non-Compliant Appeal Brief dated 
January 4, 2007, Applicants submit herewith a revised Summary of Claimed Subject 
Matter, to replace the Summary presented in the Appeal Brief dated November 21, 2006. 
SeeMPEP§ 1205.03. 



(5) SUMMARY OF CLAIMED SUBJECT MATTER 

In accordance with MPEP § 1205.02, elements recited in the claims are 
identified below with corresponding exemplary elements described in the specification. 
However, it should be understood that the claimed elements are not limited to the 
embodiment discussed below, or to the embodiments described in the specification. 

Appellants' invention concerns a method for mimicking network devices. 
A representative embodiment of a network environment in which Appellants' invention 
may be practiced is shown in Figure 1, which is reproduced below. 




FIG. I 



In Figure 1, device 20 is a mimic device which performs the methods of the 
invention. Mimic device 20 interfaces between external network 10 via network interface 
card 22 and local network 14 via network interface card 21. The local network 14 includes 
legacy or other target devices such as printers 15 and 16. The external network 10 includes 
client devices such as network server 1 1 and workstation 12, which seek access to 
functionality offered by the target devices. 
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One purpose of the invention is to provide added or improved functionality 
over that provided inherently in the target device itself. For example, the target device 
might be a legacy device that lacks a more modern functionality, such as a legacy printer 
that lacks enterprise printing functionality like secure printing or e-mail printing. For this 
purpose, mimic device 20 acts as a middle-man between external network 10 and local 
network 14, and acts transparently on behalf of target devices in response to requests for 
functionality that the target devices might not inherently support. 

Independent Claim 1 

The method of independent Claim 1 is performed in a computing device, 
such as mimic device 20, having first and second network interface cards, such as first 
network interface card 22 connecting the computing device to an external network 10, and 
second network interface card 21 connecting the computing device to a local network 14. 
(See Specification, page 12, line 31 to page 13, line 6). 

In the method of Claim 1, mimic device 20 receives an incoming message 
from a client network device residing on the external network 10, such as server 1 1 or 
workstation 12. The incoming message is addressed to a network address of a target 
network device residing on the local network 14. That is, the incoming message is 
addressed to the network address of legacy network printer 15 or legacy network printer 16. 
(See Specification, page 6, lines 27 to 32, page 30, line 7 to page 31, line 32 and Figure 
8A). 
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Thus, while the client network device on the external network sends a 
message addressed to the network address of a target device on the local network, it is 
mimic device 20 which actually receives the message. Specifically, first network interface 
card 22 and second network interface card 21 allow mimic device 20 to act as a "controlled 
bridge" receiving messages between external network 10 and local network 14. (See 
Specification, page 12, line 31 to page 13, line 2). In this way, mimic device is able to 
"act[] on behalf of legacy network devices by responding to network messages addressed to 
the legacy network devices." (Specification, page 44, lines 17 to 20; See also 
Specification, page 3, lines 27 to 30). 

In one example, these messages are addressed to the IP address of a target 
device. In representative examples from the specification, mimic device 20 "receiv[es] an 
incoming message from a client network device residing on the external network, the 
message being directed to an IP address of a designated one of the plurality of legacy 
network printers." (Specification, page 6, lines 27 to 32). In another example, "the mimic 
device intercepts requests from a client on the external network for e-mail printing from a 
network printer on the local network." (Specification, page 1 1, lines 18 to 21.) In yet 
another example, "mimic device 20 [could] act on behalf of network messages from 
external network 10 which are directed to IP addresses assigned to the printers on [a] USB 
local network." (Specification, page 45, lines 10 to 15). 

Mimic device 20 thus acts as a bridge between external network 10 and 
local network 14 and intercepts messages from client network devices (such as server 11) 
on the external network which are addressed to legacy or other target devices (such as 
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printer 15) on the local network. Therefore, while a client network device (such as server 
1 1) may send a message addressed to the IP address of a target device (such as printer 15) 
on the local network, it is mimic device 20 which receives the message. 

In Claim 1, once the message is received, mimic device 20 determines if an 
application module residing in the mimic device is configured to process a functionality 
requested by the incoming message. For example, mimic device 20 might include an e- 
mail printing application module 71 and a secure printing application module 70 as shown 
in Figure 3. 
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FIG. 3 



Mimic device 20 determines if one or more of those modules is configured 
to process the functionality requested by a message. (See Specification, page 4, lines 15 to 
21, page 26, line 24 to page 27, line 16 and page 30, line 1 to page 31, line 32). Thus, the 
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method of Claim 1 determines if an application module in mimic device 20 can process a 
requested functionality, and it makes this determination independently of whether the target 
device can or can not also provide this functionality. (See, e.g., Specification, page 4, lines 
19 to 21.) 

Claim 1 further provides that if one of the application modules in mimic 
device 20 is configured to process the functionality requested by the incoming message, 
mimic device 20 redirects the message to the application module. (See Specification, page 
7, lines 1 to 7 and page 38, lines 1 to 27). Thus, mimic device 20 can essentially override 
outdated functionality in a target device, since any message which an application module is 
configured to process is redirected to the application module, regardless of the capabilities 
of the target device. Accordingly, the functionality of the target devices can be augmented 
repeatedly by simply upgrading the application modules in mimic device 20, rather than 
updating or upgrading each individual target device on the local network. (See, e.g., 
Specification, page 44, lines 8 to 22). 

On the other hand, Claim 1 also provides that if an application module is 
not configured to processed the functionality in the incoming message, mimic device 20 
passes the incoming message through the local network to the target network device 
residing on the local network. (See Specification, page 37, line 32 to page 38, line 17). 

Independent Claim 33 

The method of independent Claim 33 is performed in a computing device, 
such as mimic device 20, having first and second network interface cards, such as first 
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network interface card 22 connecting the computing device to an external network 10 and 
second network interface card 21 connecting the computing device to a local network 14. 
(See Specification, page 12, line 31 to page 13, line 6). 

In the method of Claim 33, mimic device 20 discovers a plurality of target 
network devices on local network 14, such as printers 15 and 16, by detecting messages on 
local network 14 from each of the plurality of target network devices. (See Specification, 
page 6, lines 17 to 20, page 23, line 1 to page 24, line 10 and Figure 5.) 

Additionally, in Claim 33, mimic device 20 creates a rule in a rules table for 
each of the discovered target network devices. Rules tables are shown at Figure 3, which 
was reproduced above. Each rule contains the IP address of the corresponding target 
network device and indicates whether an application module in the computing device is 
configured to perform a function on behalf of the corresponding target network device. As 
a concrete example, the rules tables include IN table 110, which is discussed at page 30 and 
shown in Figure 8A. (See Specification, page 5, lines 17 to 25, page 30, line 1 to page 31, 
line 32 and page 34, line 17 to page 35, line 7; see also Figures 8A and 12). 
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FIG. 8A 



As claimed in Claim 33, mimic device 20 receives an incoming message 
from a client network device residing on the external network 10, such as server 1 1 or 
workstation 12. The incoming message is addressed to an LP address of a designated one 
of the plurality of target network devices. (See Specification, page 6, lines 27 to 32 and 
page 30, line 7 to page 31, line 32; see also page 11, lines 18 to 21). That is, the incoming 
message is addressed to the IP address of legacy network printer 15 or legacy network 
printer 16. 

Thus, while the client network device on the external network sends a 
message addressed to the IP address of a target device on the local network, it is mimic 
device 20 which actually receives the message, as discussed in detail above in connection 
with the method of Claim 1 . Mimic device 20 therefore acts as a bridge between external 
network 10 and local network 14, and intercepts messages from client network devices 
(such as server 1 1) on the external network which are addressed to the IP address of legacy 
or other target devices (such as printer 15) on the local network. 

In Claim 33, once the message is received, mimic device 20 determines if 
the incoming message requests a functionality that the application module is configured to 
perform, based at least in part on the rule corresponding to the designated target network 
device. (See Specification, page 6, line 32 to page 7, line 2, page 30, line 1 to page 31, 
line 32 and Figure 8 A). Thus, the method of Claim 33 determines if an application module 
in mimic device 20 is configured to perform a requested functionality, and it makes this 
determination independently of whether the target device can or can not also provide this 
functionality. (See, e.g., Specification, page 4, lines 19 to 21.) 
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Claim 33 further provides that if that the incoming message requests a 
functionality that the application module is configured to perform, mimic device 20 
redirects the incoming message to the application module, which performs the requested 
functionality in response to the incoming message. (See Specification, page 7, lines 1 to 7 
and page 38, lines 1 to 27). 

Thus, in the method of Claim 33, mimic device 20 can essentially override 
outdated functionality in a target device, since any message which an application module is 
configured to perform is redirected to the application module and performed by the 
application module, regardless of the capabilities of the target device. Accordingly, as 
discussed above in connection with Claim 1, the functionality of the target devices can be 
augmented repeatedly by simply upgrading the application modules in mimic device 20, 
rather than updating or upgrading each individual target device on the local network. 

On the other hand, Claim 33 also provides that if the incoming message 
does not request a functionality that the application module is configured to perform, 
mimic device 20 passes the incoming message through the local network to the designated 
target network device. (See Specification, page 7, lines 7 to 1 1 and page 37, line 32 to 
page 38, line 17). 

By virtue of the foregoing arrangements, the mimic device 20 may act as a 
"middle man" to augment the functional capabilities of legacy devices or other target 
devices on a network which lack a desired functionality, ordinarily without the need to add 
potentially expensive or inefficient software or hardware upgrades to each individual 
device. 



Applicants* undersigned attorney may be reached in our Costa Mesa, 
California office at (714) 540-8700. All correspondence should continue to be directed to 
our below-listed address. 

Respectfully submitted, 

Michael K. O'Neill 
Attorney for Applicants 
Registration No.: 32,622 
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